…accidentally been

removed in rust-lang#89597.

Also describe vtables as structs with a field for each entry.

…view comments

We recently removed the "up here" arrows on item-infos, and adjusted
vertical spacing so that even without the arrow, it would be visually
clear which item the item-info belonged to. The new CSS styles for
vertical spacing only applied to toggles, though. This missed
non-toggled impl blocks - for instance, those without any methods, like
https://doc.rust-lang.org/nightly/std/marker/trait.Send.html#implementors.
The result was lists of implementors that were spaced too closely. This
PR fixes the spacing by making it apply to non-toggled impl blocks as
well.

This also fixes an issue where item-infos were displayed too far below
their items. That was a result of display: table on .item-info .stab.
Changed that to display: inline-block.

…ice, r=wesleywiser

Better suggestions when user tries to collect into an unsized `[_]`

1. Extend the predicate on `rustc_on_unimplemented` to support substitutions like note, label, etc (i.e. treat it as a `OnUnimplementedFormatString`) so we can have slightly more general `rustc_on_unimplemented` special-cases.
2. Add a `rustc_on_unimplemented` if we fail on `FromIterator<A> for [A]` which happens when we don't explicitly collect into a `vec<A>`, but then pass the return from a `.collect` call into something that takes a slice.

Fixes rust-lang#91423

`#[used(linker)]` attribute

See dtolnay/linkme#41 (comment).

…debuginfo-regression, r=wesleywiser

debuginfo: Fix DW_AT_containing_type vtable debuginfo regression

This PR brings back the `DW_AT_containing_type` attribute for vtables after it has accidentally been removed in rust-lang#89597.

It also implements a more accurate description of vtables. Instead of describing them as an array of void pointers, the compiler will now emit a struct type description with a field for each entry of the vtable.

r? `@wesleywiser`

This PR should fix issue rust-lang#93164.
~~The PR is blocked on rust-lang#93154 because both of them modify the `codegen/debug-vtable.rs` test case.~~

…henkov

Complete removal of #[main] attribute from compiler

resolves rust-lang#93786

---

The `#[main]` attribute was mostly removed from the language in rust-lang#84217, but not completely. It is still recognized as a builtin attribute by the compiler, but it has no effect. However, this no-op attribute is no longer gated by `#[feature(main)]` (which no longer exists), so it's possible to include it in code *on stable* without any errors, which seems unintentional. For example, the following code is accepted ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)).

```rust
#[main]
fn main() {
    println!("hello world");
}
```

Aside from that oddity, the existence of this attribute causes code like the following to fail ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=use%20tokio%3A%3Amain%3B%0A%0A%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). According rust-lang#84062 (comment), the removal of `#[main]` was expected to eliminate this conflict (previously reported as rust-lang#62127).

```rust
use tokio::main;

#[main]
fn main() {
    println!("hello world");
}
```

```
error[E0659]: `main` is ambiguous
 --> src/main.rs:3:3
  |
3 | #[main]
  |   ^^^^ ambiguous name
  |
  = note: ambiguous because of a name conflict with a builtin attribute
  = note: `main` could refer to a built-in attribute
```

[This error message can be confusing](https://stackoverflow.com/q/71024443/1114), as the mostly-removed `#[main]` attribute is not mentioned in any documentation.

Since the current availability of `#[main]` on stable seems unintentional, and to needlessly block use of the `main` identifier in the attribute namespace, this PR finishes removing the `#[main]` attribute as described in rust-lang#29634 (comment) by deleting it from `builtin_attrs.rs`, and adds two test cases to ensure that the attribute is no longer accepted and no longer conflicts with other attributes imported as `main`.

…umeGomez

rustdoc: fix spacing of non-toggled impl blocks

We [recently removed the "up here" arrows on item-infos](rust-lang#92651), and adjusted
vertical spacing so that even without the arrow, it would be visually
clear which item the item-info belonged to. The new CSS styles for
vertical spacing only applied to toggles, though. This missed
non-toggled impl blocks - for instance, those without any methods, like
https://doc.rust-lang.org/nightly/std/marker/trait.Send.html#implementors.
The result was lists of implementors that were spaced too closely. This
PR fixes the spacing by making it apply to non-toggled impl blocks as
well.

This also fixes an issue where item-infos were displayed too far below
their items. That was a result of display: table on .item-info .stab.
Changed that to display: inline-block.

Demo: https://rustdoc.crud.net/jsha/re-space-empty-impls/std/marker/trait.Send.html

Before:

<img width=300 src="https://user-images.githubusercontent.com/220205/152954394-ec0b80e7-2573-4f06-9d7a-7b10b8ceac60.png">

After:

<img width=300 src="https://user-images.githubusercontent.com/220205/152954228-abac1d30-a76d-4ab1-89ec-ef7549fe8c9c.png">

r? `@GuillaumeGomez`

Fix typo in `std::fmt` docs

Hey!

Reading the docs (https://doc.rust-lang.org/std/fmt/#named-parameters), this seems like a typo?

The docs here also seem to mix “named argument” and “named parameter”? Intentional? Mistake?